<html>
  <!--  -->
  <head>
    <title>Implementation of location forwarding</title>
  </head>
  
  <BODY text = "#000000"
    link="#0000ff"
    vlink="#cc0000"
    bgcolor="#ffffff">
    
    <body>
      <HR>
	<h1>Location forwarding</h1>
	<HR>
	  <h2>Context</h2>

	  The motivation to support location forwarding for objects is
	  to allow objects to move or forward certain requests to
	  other objects.  Moving of objects is very important for the
	  Common Object Services LifeCycle Service. An object
	  complying to the LifeCycleObject interface, defined by the
	  LifeCycle Service should support the move() operation. The
	  move() operation allows the client to keep its object
	  reference to the object, but the object is going to be
	  relocated on the same or a different server.  Making
	  location forwarding transparent to the client is the most
	  important issue.
	  
	  <h2>Communication between server and client</h2>

	  GIOP defines a message named "LOCATION_FORWARD", which
	  should be used to inform the client stub, that the object
	  has been moved. The message body has to contain an object
	  reference to the new location of the forwarded object.
	  	  
	  <h2>Server side implementation</h2>

	  Two approaches are possible, one is to use a POA servant
	  locator and the other is to use a servant activator. 
	  
	  <h2>Client side implementation</h2>

	  The client has to expect the location forwarding GIOP
	  message and should respond to it in setting the Profile of
	  its Object right.	  
	  
	  <h2>Conclusion</h2>

	  Changing the Profile is transparent to the client. So the
	  client gets no idea that the object now resides somewhere
	  else.
	  	  
	  The result of the above mentioned solution is that if an
	  object moves the client will notice it with the next call to
	  the object. If the object moves again, the original location
	  is not bothered at all again. Say if the original location
	  was A, then it moved to B and finally to C. First location A
	  responded with a GIOP Location Forward to the client, then B
	  gets used and finally after moving the object to C, B will
	  send a GIOP Location Forward and location C gets used.

	  There is "no" concept of a home location. If the object
	  moves very often and old servers die it might be a problem,
	  because clients, which did not call on the object lately
	  will not know where to search. Though in the situation of a
	  home location, there is also the risk that this server might
	  die and the object is not reachable any more.

	  <h2>Optimization</h2>

	  In the case, when the object moves several times, a chain of
	  forwarding servers is created. But this chain might be
	  easily disturbed by just one server failing. A good idea is
	  to give the servant locator more intelligence to tell all
	  the other/previous servers where the object is now.  This
	  will of course increase the communication overhead in the
	  case of a move, but we get a high reliability against dying
	  hosts.
 
	  <HR>
	    For more details and questions,
	    <p>
	      
	      <address><a href="mailto:mk1@cs.wustl.edu">Michael Kircher</a></address>
	      <p>
		<address><a href="mailto:irfan1@cs.wustl.edu">Irfan Pyarali</a></address>
    </body>
</html>

